Hello, 各位 iT 邦幫忙 的粉絲們大家好~~~

這系列文源自這幾年在團隊裡導入 AI Coding 之後，一路踩雷、修正、再踩雷的真實過程。把這些收斂出來的方法整理成文，也許對正在煩惱同樣問題的你會有些幫助。

就當作是一份邊做邊記的工程筆記吧！

本篇是 當 AI 加入團隊：打造可審查、可驗證、會自我改善的 AI 開發工作流 系列文的 EP04。

單一技能解決的是「這件事怎麼做」。但真實世界的任務往往是好幾件事串起來的：收到一張問題單、下載相關日誌、找出根因、修正、驗證、最後提交變更。

如果每次都讓 AI 臨場自己決定順序，結果會很不穩定——有時候會漏掉驗證這一步，有時候會提交了還沒真正修好的東西。

所以我們接著建立了第一個完整的 workflow，把整條路徑寫清楚。

一份 workflow 大致長這樣：

{
  "name": "issue-fix-and-commit",
  "description": "分析一張問題單、找出根因、修正、驗證，並在目標 repo 提交。",
  "inputs": ["issue_id", "repo_path"],
  "steps": [
    "讀取問題單內容與相關日誌",
    "定位根因並提出修正",
    "執行既有測試或最小可驗證檢查",
    "提交變更並附上驗證證據"
  ],
  "done_when": "測試通過，且提交訊息附上根因說明與驗證方式"
}

這裡的關鍵轉變是：AI 不再只是被要求「產生一個答案」，而是被要求依照團隊定義好的順序工作，並且在結束時留下可以被檢查的證據——例如驗證指令實際跑了什麼、輸出是什麼，而不是一句「應該沒問題了」。

workflow 和 skill 的分工也慢慢清楚了：workflow 負責安排「一連串能力的執行順序」，skill 負責提供「其中一項可重複使用的能力」。這個分工在後面很多篇裡都會不斷被拿出來當判斷依據。

流程有了，接下來要處理一個很現實的問題：任務跑完會留下一堆暫存檔案、日誌、下載資料，這些東西該放在哪？下一篇見。